Re: [DNSOP] Fundamental ANAME problems

Paul Vixie <paul@redbarn.org> Mon, 05 November 2018 17:32 UTC

Return-Path: <paul@redbarn.org>
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 0E6581277CC for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 09:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, 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 oP2eX_2DaL4E for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 09:32:45 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D672127133 for <dnsop@ietf.org>; Mon, 5 Nov 2018 09:32:45 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:8de1:7fa:37ed:8cc4] (unknown [IPv6:2001:559:8000:c9:8de1:7fa:37ed:8cc4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BB4CB892C6; Mon, 5 Nov 2018 17:32:44 +0000 (UTC)
Message-ID: <5BE07EBC.1010603@redbarn.org>
Date: Mon, 05 Nov 2018 09:32:44 -0800
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ray Bellis <ray@bellis.me.uk>
CC: 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>
In-Reply-To: <770d5dc8-b8a3-c1c3-553f-0e9504389750@bellis.me.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ro0tzebqL7BQMnbkp8FrW95KoxU>
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 17:32:47 -0000

there were several pro-HTTP-URI comments in this thread; i picked the 
one with the most technical meat. brian, jim, paul: thank you for your 
comments.

Ray Bellis wrote:
> 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.

on that basis, i would ordinarily withdraw my objection, since the 
needed functionality is just not present in the existing code point.

> 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.

please don't think this way, and don't do the right thing for the wrong 
reasons. the paragraph above is how the camel came to be -- one draft at 
a time, all well-meaning.

the fully loaded long term cost to the economy of an "if" statement in a 
widely deployed C program is about USD 10.000. we should never add to 
this externalized cost unless we have a compelling reason to do so. "the 
web people don't want even one extra RTT, ever" is not compelling. "the 
web people need wildcards to work which they don't in SRV" however, is 
compelling.

> 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.

as may be, this looks like an argument over who has to fetch the data. 
the browser people don't want it to be them. i can't blame them, but the 
reason SRV specifies opportunistic rather than mandatory additional data 
is to keep the recursive DNS server from both fetching and caching (and 
now, validating) the AAAA/A, from having to keep the SRV transaction 
open longer (while its mandatory AAAA/A additionals are fetched and 
before the very first answer, a possibly soft cache-miss, is sent), and 
to avoid loading the network with a query whose answer might not be used 
(something else about the SRV response might have caused a failure in 
the www transaction such that the AAAA/A is never needed.)

those were solid and still-valid engineering-technology and 
engineering-economics considerations. when we add "HTTP URI" we do so at 
costs greater than a code point. and even the code point has to add some 
"if" statements to the globally deployed system. that won't be cheap, 
merely externalized. a cheeseburger that externalizes USD 10 of 
environmental cleanup costs onto the economy is still a USD 10 
cheeseburger, even if it only costs USD 0,25 to make and has a consumer 
price of USD 1.

-- 
P Vixie