On Fri, Oct 18, 2024 at 01:53:08PM +0200, Ted Lemon wrote:
> OLD:
> Any other
> response, specifically including a value that will return a CNAME
> record when queried, lies outside the scope of this Standard. The
> prohibition on labels in the data that resolve to CNAMEs is discussed
> in more detail in RFC 2181, Section 10.3 [33].
> NEW:
> An MX record with a CNAME as its target is a misconfiguration, as explained
> in RFC2181, Section 1.3 [33].
> However, implementations SHOULD still process CNAME responses when
> received, since a significant number of
> servers on the internet are configured with MX records pointing to CNAMEs.
Not bad, but I think that ~1% is more "non-negligible" than
"significant".
On Fri, Oct 18, 2024 at 05:19:35PM -0400, John Levine wrote:
> It appears that Viktor Dukhovni <emailcore@xxxxxxxx> said:
> If you want to forbid CNAMEs, the application has to add special
> checks to notice the CNAMEs and object to them.
This of course depends on the API used. If it is just getaddrinfo() and
friends, then indeed yes. But carefully designed MTAs will resort to
explicit DNS lookups when resolving SMTP server names obtained from DNS,
so as to avoid namespace confusion, so may well end up seeing the CNAME
as part of decoding the DNS response. Though of course, even then the
resolver will typically have performed the iteration, and returned a
chain plus any addresses.
> Hence in section 5.1. I would say that for maximum compatibility with
> earlier versions of this standard, recipient mail systems MUST NOT use
> CNAMEs to refer to MX records or the A or AAAA records that an MX
> points to.
Actually, only the latter. The domain part of an email address is in
fact explicitly allowed in 5321 (don't recall whether also 2821) to be
a CNAME chain leading to the actual MX RRset.
> Nonetheless, sending mail systems SHOULD resolve CNAMEs in those
> contexts the same way that they do everywhere else. This is
> deliberately different from what the current text says. The SHOULD is
> so that the existing behavior remains conformant.
Yes, it may be best to match operational reality.
> Bonus question: the current text says nothing about DNAME. Well? Same thing,
> the library will resolve it unless you tell it not to so we might as well allow it.
DNAMEs are not relevant, they're used for CNAME synthesis only, and so
all the MTA sees is any resulting CNAMEs. The actual owner name of
a DNAME is a regular name that may or may not have MX, A, AAAA or
other records, so the DNAME won't show up when making MX or A queries,
while subdomains of the DNAME are redirected via CNAME synthesis, so
again the DNAME is generally invisible to MTAs unless they decide to
perform DNSSEC validation of synthesised names, rather than trust the
resolver AD bit (or just be DNSSEC-agnostic).
> PS: In answer to the question how many levels of CNAME to allow, the
> only answer is whatever your DNS library does. The dnsop WG has
> declined to set specific limits on CNAME or DNAME or any of the many
> other ways you can make long chains of DNS lookups, and we sure aren't
> going there either.
Postfix picked 10 IIRC.
On Fri, Oct 18, 2024 at 05:52:23PM -0400, John C Klensin wrote:
> * If one asks the DNS for an MX record and gets a CNAME, that is ok:
> the query is just repeated "with the canonical domain name"
Yes, and generally that happens inside the resolver, with the MTA
seeing the result of the restart.
> * The arguments to MX are the preference value and "the name of a
> host". That was widely interpreted as not allowing any name in that
> field that would resolve to anything but an address record.
That was 40 years ago, and these days there's not much evidence that
there are MTAs that care to restrict CNAMEs in the exchange field,
however also there is general awareness they should be avoided, and
~99% of the names are not CNAMEs.
> In addition, RFC 1123 requires (Section 5.2.2) that the domain name
> in the MAIL or RCPT commands MUST either be a domain literal,
> identify a host directly, or lead to MX record(s); it cannot be a
> CNAME.
That was later superceded in either 2821 or 5321. There are now
email domains that are CNAMEs to other domains.
> * Also from 1123: Names that lead to MX records cannot be used in
> HELO (5.2.5)
This seems rather outdated.
> Several of those restrictions have been relaxed over the years but the
> relationship between the original rules and the relaxed ones have been
> (or at least were for many years) a source of confusion about the
> behaviors that can be expected by systems that conforming to one spec
> or another.
>
> I suspect that some of the text in the current draft that now looks
> convoluted (substantially none of which was written later than RFC
> 5321) may be due to that original text and efforts to relax the
> rules. I have no idea whether similar confusion is driving some of
> the recent discussion, but would encourage people to think about it.
I don't think there's any significant confusion on the part of either
MTA operators or MTA implementors. Basically, CNAMEs are rarely used
by the former, and tolerated by the latter. The only confusion I see
is here in the working group, with not everyone recalling the precise
rules, or being unsure of the history.
> Again, further discussion to emailcore@xxxxxxxx only, please -- I've
> very concerned that, if new issues are raised on the Last Call list,
> they may get lost in the back-and-forth about this one.
--
Viktor.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
