Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Tony Finch <dot@dotat.at> Tue, 19 June 2018 16:44 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC32913117F for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 09:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 b_5YazsLDGvc for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 09:44:37 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677C9130E07 for <dnsop@ietf.org>; Tue, 19 Jun 2018 09:44:37 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:43977) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fVJkB-0009jl-1Z (Exim 4.91) (return-path <dot@dotat.at>); Tue, 19 Jun 2018 17:44:35 +0100
Date: Tue, 19 Jun 2018 17:44:35 +0100
From: Tony Finch <dot@dotat.at>
To: Jared Mauch <jared@puck.nether.net>
cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
In-Reply-To: <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net>
Message-ID: <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk> <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-62862578-1529426675=:916"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Qu4uTsKl4kf1AVUtteG1s8VlxQQ>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2018 16:44:40 -0000

... going wildly off-topic now ...

Jared Mauch <jared@puck.nether.net>; wrote:
>
> Throw some shade at SMTP as well, if I send mail to
> jared@cname.nether.net and that pointed to @nether.net it would end up
> as @nether.net in the messages :-)

Not always - Exim doesn't do that rewrite, for example. CNAME-driven
rewrites were removed in RFC 2822, but some MTAs are still partying like
it's 1988.

> This doesn’t mean the internals aren’t important, but many application
> developers and end-users can’t be expected to know/care about how a
> CNAME at apex differs from an A record w/ redirector.

In my experience, many of them don't really understand the distinction
between web site names and server names, or between CNAME indirection and
HTTP redirection.

> One thing that SMTP got right was MX records, so it’s easier to say “go
> over here”.  While I’m sure someone will say that HTTP should have it’s
> own (eg: SRV) but the barn door is still open, etc..

The key thing that SMTP got right was explicitly mentioning the complete
target address in-band in the protocol: SMTP doesn't assume that the
server implicitly knows what it is called. But this feature (and MXs) was
driven by mail's prolific and baroque gatewaying.

The DNS also got the same thing right. I guess in its case the right
solution was a result of looking at zones as database keys rather than as
service endpoints.

It's sort of weird that this architectural lesson took so long to be
learned by other protocols. I was relatively late to the party: at the
time I got involved in HTTP (1997), name-based virtual hosting was just
about starting to become usable, but we were still rolling out new
IP-based vhosting setups. And of course the same story was repeated for
TLS a decade later.

SRV should have been part of the fix (and it was invented early enough to
be!) but it wasn't a complete fix without support from the application
protocols.

The other thing that SRV tried to do, but didn't quite succeed, was to
liberate us from well-known port numbers. Another way we might have done
mass hosting in the late 1990s, if SRV had been deployed, could have been
port-based virtual hosting. Though that would have had interesting effects
on kernel and web server performance that we avoided with name-based and
IP-based vhosting...

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
Sole: South 4 or 5, becoming variable 3. Moderate, occasionally rough in west.
Drizzle, fog patches. Moderate, occasionally very poor.