Re: [ietf-smtp] CNAME considered harmful, was MTS-STS validation when MX host points to a CNAME

John C Klensin <john-ietf@jck.com> Sun, 04 April 2021 20:47 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D03A19A6 for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 13:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbUOIG4B7bLR for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 13:47:24 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4718B3A19A4 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 13:47:24 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lT9dy-000CoV-JG; Sun, 04 Apr 2021 16:46:50 -0400
Date: Sun, 04 Apr 2021 16:46:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>, ietf-smtp@ietf.org
Message-ID: <CE1A5C2A0DC3BEE8A9CBD4BF@JcK-HP5>
In-Reply-To: <373c48af-10fa-3811-afc-1e08adcd13@taugh.com>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <373c48af-10fa-3811-afc-1e08adcd13@taugh.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/IcL5-823B2dhgj1Da3w4J6WAsXo>
Subject: Re: [ietf-smtp] CNAME considered harmful, was MTS-STS validation when MX host points to a CNAME
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Apr 2021 20:47:29 -0000


--On Sunday, 04 April, 2021 13:00 -0400 John R Levine
<johnl@taugh.com> wrote:

>> No, and my apologies if parts of what follow sounds like a
>> rant.
> 
> Thanks, I'd forgotten about the RFC 1123 language.
> 
>> Once upon a time, we used to try to design protocols so that
>> the functionality that was needed was available but that the
>> number of different ways to do something was minimized, more
>> or less on the assumption that two or three ways to do the
>> same thing created opportunities for errors, ...
> 
> Yes indeed.  In retrospect, CNAME was a mistake.  If you look
> at RFC 1034, you can see that the motivation for CNAME was to
> provide short local versions of names and temporary forwarding
> when a host name changes. But now it's mostly used to transfer
> the management of a name to someone else.
> 
> The normal way to do that is with a zone cut, and I think that
> most applications of CNAME would better be done with NS.
> There are two differences: a zone cut needs to know what name
> is pointing at it and a zone cut covers all names below the
> redirected one while a CNAME doesn't, but in my experience,
> the situations where that matters generally have other
> problems.

I would say (and have said) much the same thing, even more
strongly, about DNAME and its purpose.  The original
specification for DNAME says that too.  But the big design
error, in retrospect, was to confuse the function of an
alternate name for a node (accomplished in the host table with a
simple alias) with a pointer or link to somewhere or something
else, most likely in a different zone.  The problem has become
especially clear in recent years every time someone tries to use
CNAME (or DNAME) to try to support an alternate spelling or
different-script form for a given node name: the bindings are
not strong enough, there is no way to ask the DNS what all of
the names are that refer to a given node, etc.

And, if I didn't say more or less that in RFC 8324, I should
have.

    john