[DNSOP] ANAME intro text

Ray Bellis <ray@bellis.me.uk> Tue, 30 October 2018 14:58 UTC

Return-Path: <ray@bellis.me.uk>
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 3DDCE1293FB for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 07:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 SYvD4wVtcvom for <dnsop@ietfa.amsl.com>; Tue, 30 Oct 2018 07:58:30 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6DB128CFD for <dnsop@ietf.org>; Tue, 30 Oct 2018 07:58:29 -0700 (PDT)
Received: from [88.212.170.147] (port=60924 helo=Rays-MacBook-Pro.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1gHVTN-0004Fi-2y (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Tue, 30 Oct 2018 14:58:25 +0000
To: dnsop@ietf.org
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <0181da24-c213-00b5-5023-db7459e5e494@bellis.me.uk>
Date: Tue, 30 Oct 2018 14:58:26 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------8E6EE43268FA0A31F566B82E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Uh-wp_b-sHzVlqaR1BgGDU47HlU>
Subject: [DNSOP] ANAME intro text
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Oct 2018 14:58:32 -0000

The introduction of draft-ietf-dnsop-aname-02 includes this text:

   If the web site is hosted by a third-party provider, the ideal way to
   provision its name in the DNS is using a CNAME record, so that the
   third party provider retains control over the mapping from names to
   IP address(es).

I have some issue with the use of the term "ideal" there.  At best it's
merely "expedient", but either way it'ws an abuse of the true original
semanatics of the CNAME record.

AIUI, various protocols have at times required that when a CNAME record
is encountered that the target of that record (the "canonical name") be
the one subsequently used in protocol exchanges.  [e.g. the apparently
obsolete text in ยง5.2.2 of RFC 1123].

This reinforced the semantic that the RHS of a CNAME is the "one true
name" and that the owner name is just an alias for it [RFC 2181].

Browsers, unfortunately, never did this.  Name-based virtual hosting
actually required the opposite - you have to put the original owner name
in the 'Host:' header.

If we've moved to a world where those original semantics really no
longer apply, I think that needs to be written down in a consensus
document somewhere.

Ray