Re: [DNSOP] Minimum viable ANAME

Paul Vixie <paul@redbarn.org> Sat, 03 November 2018 23:53 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 1DE671294D0 for <dnsop@ietfa.amsl.com>; Sat, 3 Nov 2018 16:53:11 -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 YuMYnKcCTrb7 for <dnsop@ietfa.amsl.com>; Sat, 3 Nov 2018 16:53:09 -0700 (PDT)
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 9EC3B1292AD for <dnsop@ietf.org>; Sat, 3 Nov 2018 16:53:09 -0700 (PDT)
Received: from [10.0.29.176] (unknown [12.169.103.93]) (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 2F20E892C6; Sat, 3 Nov 2018 23:53:08 +0000 (UTC)
Message-ID: <5BDE34E3.5030602@redbarn.org>
Date: Sat, 03 Nov 2018 16:53:07 -0700
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: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk>
In-Reply-To: <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@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/V021k8h2C14EFh9rYQC9MqoDsa0>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Sat, 03 Nov 2018 23:53:11 -0000


Ray Bellis wrote:
>
>
> On 21/09/2018 20:12, Dan York wrote:
>
>> I do think this is a path we need to go.  We need *something* like
>> CNAME at the apex.  Either CNAME itself or something that works in the
>> same way but might have a different name.
>
> I agree, and earlier today (well, yesterday, now) I wrote it up:
>
> A new version of I-D, draft-bellis-dnsop-http-record-00.txt
> has been successfully submitted by Ray Bellis and posted to the
> IETF repository.
> ...

the arguments against SRV in that document are unsupported and wrong.

>    While there have been previous attempts to promote the use of the SRV
>    record instead of CNAME records, there have been concerns raised
>    about the performance impact of the additional DNS lookup an SRV
>    record would typically require.

SRV responses include additional data.

>    To achieve equivalent end-user performance as existing CNAME-based
>    solutions, this document permits recursive resolvers to pre-emptively
>    look up the target of an HTTP Record and return the corresponding
>    records to the client.  While this feature is not mandatory it is
>    hoped that support would over time become near ubiquitous.

i think that makes HTTP as fast in terms of round trips as SRV is.

>    Also, the presence of the Port field in an SRV record is incompatible
>    with the "Same Origin" security policy enforced by web browsers and
>    in practise the load-balancing / fallback capabilities of the SRV
>    record are not widely used either, ...

so use "0" for the port number, and don't include more than one SRV RR.

>    ... and non-DNS based solutions for
>    this are already widely deployed for HTTP traffic.

so just keep using non-DNS solutions.

there's no benefit to accompany the cost of this proposal compared to 
re-use of existing code points which are already broadly implemented.

the HTTP folks are obviously not interested in round trips, anyway:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37345
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
; COOKIE: 5a8f3fa2fa447f4c (echoed)
;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME 
www.microsoft.com-c-3.edgekey.net.

;; Query time: 23 msec
;; SERVER: 2620:0:30::53#53(2620:0:30::53)
;; WHEN: Sat Nov 03 23:52:17 UTC 2018
;; MSG SIZE  rcvd: 105

-- 
P Vixie