IETF Logo Mail Archive

Re: [DNSOP] Fundamental ANAME problems

Ray Bellis <ray@bellis.me.uk> Mon, 05 November 2018 15:38 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 0087B130DE6 for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 07:38:14 -0800 (PST)
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 1HLvp09VdvWh for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 07:38:11 -0800 (PST)
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 BA22712D7F8 for <dnsop@ietf.org>; Mon, 5 Nov 2018 07:38:11 -0800 (PST)
Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:54574 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 1gJgx3-0003eL-Op (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Mon, 05 Nov 2018 15:38:07 +0000
To: dnsop@ietf.org
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk> <20181105083526.GA12204@besserwisser.org> <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <770d5dc8-b8a3-c1c3-553f-0e9504389750@bellis.me.uk>
Date: Mon, 05 Nov 2018 22:38:04 +0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/U3p4tutYMCtm9rcqMkawZxJZwCE>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Mon, 05 Nov 2018 15:38:14 -0000


On 05/11/2018 18:55, Joe Abley wrote:

> 2. Find a client-side solution to this, and try really hard not to 
> invent something new that is really just SRV with a hat and a false 
> moustache.

There *is* a big failing of SRV that's independent of the CNAME apex use 
case, and that is its lack of support for wildcards.  Since my proposal 
doesn't use underscore prefix labels, wildcards will work, and this is 
an important requirement for some large website operators.

The cost to the DNS community of *trying* my proposed HTTP record is 
pretty negligible.  Worst case, as Brian put it, is we burn a code 
point, add a trivial amount of code to DNS servers, but the browsers 
don't adopt it.  It wouldn't be the first time, it won't be the last.

However, it only takes one of the big browser vendors to decide they'll 
support it and I think the rest will shortly thereafter follow suit.

NB: this proposal currently satisfies the criteria for assignment via
expert review per RFC 6895.

Ray

v2.26.15 | Report a Bug | By Email | System Status