Re: [DNSOP] Fundamental ANAME problems

Ray Bellis <ray@bellis.me.uk> Tue, 06 November 2018 00:43 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 55ABF128D09 for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 16:43:35 -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 vSuVPBq9WIcE for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 16:43:33 -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 F1438126DBF for <dnsop@ietf.org>; Mon, 5 Nov 2018 16:43:32 -0800 (PST)
Received: from cm-114-109-178-6.revip13.asianet.co.th ([114.109.178.6]:58940 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 1gJpSn-0001v3-RQ (Exim 4.72) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Tue, 06 Nov 2018 00:43:26 +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> <770d5dc8-b8a3-c1c3-553f-0e9504389750@bellis.me.uk> <CAJhMdTODiJ7DvN5=sFnvEj-FP=M=2yDN_enk17Bo=En9V8bLjw@mail.gmail.com>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <8b5f6d3b-9744-1716-c04b-c5b888c924a4@bellis.me.uk>
Date: Tue, 06 Nov 2018 07:43:25 +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: <CAJhMdTODiJ7DvN5=sFnvEj-FP=M=2yDN_enk17Bo=En9V8bLjw@mail.gmail.com>
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/auFzVuB2JQ1La8yM-V1HWOkfegQ>
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: Tue, 06 Nov 2018 00:43:35 -0000


On 06/11/2018 04:07, Joe Abley wrote:

> Specifically, I s the wildcard owner name a real problem in the grand
> scheme of things? I understand that wildcards are used by some people
> for names that feature in HTTP URIs, but I'm struggling to imagine
> using a wildcard at a zone cut; [...]

You're not wrong, because most often the wildcard is indeed a label 
below that cut.

However, the intent is that this record would eventually replace *all* 
use of CNAME for web redirection regardless of whether at the zone cut 
or not.

This isn't a wildcard example, but here's a re-post of a currently 
impossible zone configuration from one of my emails Sunday:

$ORIGIN example.com
@                IN SOA   ...
                  IN NS    ...
company-division IN MX    <company mail system>
company-division IN CNAME <cdn web host>

Replacing that CNAME with HTTP makes this configuration possible.

> To be clear, the rules are clear and you should feel as empowered as
> anybody to apply for an early assignment of an RRTYPE and start
> writing code. If I sounded like I was arguing against that I
> definitely apologise!

No worries! :)

> However I think that a more coordinated approach that involves people
> from both web and DNS communities to understand the problem space is
> more sensible, though, and more likely to be productive for this
> working group. It's not clear to me that either community has a great
> track record just guessing at what the other one wants.

I've been actively socialising this with web people since Saturday even 
before the draft was submitted.  I'm going to be talking about it 
briefly at HTTP-bis this morning.

This draft is IMHO not so much a "guess", but a "starting point" based 
on what web folks said at the side meeting in Montreal.

Yes, it'll require browser implementors to update their code, but the 
alternative is breaking the camel's back.

cheers,

Ray