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

Ray Bellis <> Mon, 17 September 2018 07:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB32E130DC3 for <>; Mon, 17 Sep 2018 00:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dqUij-nluafD for <>; Mon, 17 Sep 2018 00:29:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EFD6130DF1 for <>; Mon, 17 Sep 2018 00:29:57 -0700 (PDT)
Received: from [] (port=62081 helo=Barbaras-MacBook-Pro.local) by ([]:465) with esmtpsa ( (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1g1nyl-0007qb-6f (Exim 4.72) for (return-path <>); Mon, 17 Sep 2018 08:29:55 +0100
References: <> <20180916095655.GA11121@jurassic> <> <> <>
From: Ray Bellis <>
Message-ID: <>
Date: Mon, 17 Sep 2018 08:29:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Sep 2018 07:30:01 -0000

On 17/09/2018 08:11, Stephane Bortzmeyer wrote:

> Since the main use case is "people with a domain name such as
>, who wants to actually work, and who
> hosts the stuff at a CDN where the IP address is wildly variable so
> they cannot use A or AAAA records", I suggest that this use case is
> better solved by using SRV records for HTTP. True, it seems
> unrealistic that it will be specified and deployed but it is also the
> case for the DNS "CNAME at apex" change.

We heard at the side meeting in Montreal that SRV doesn't meet the 
requirements, in part because it has features that are considered 
incompatible with the web origin model (i.e. the port field).

I do believe we need a new DNS type code that is designed in cooperation 
with the HTTP community and I've suggested as such on the http-srv 
mailing list, but so far there's little engagement.

There was a suggestion that the proposed ALT-SVC RR could be used, but 
IMHO it has significant issues that would need to be resolved first.