Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

Mark Andrews <marka@isc.org> Thu, 08 November 2018 20:13 UTC

Return-Path: <marka@isc.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 DCAB61200D7 for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 12:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 dqeIXYQqvAfk for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 12:13:52 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D6F127133 for <dnsop@ietf.org>; Thu, 8 Nov 2018 12:13:52 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3634E3AB8A1; Thu, 8 Nov 2018 20:13:52 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 13E8F16007F; Thu, 8 Nov 2018 20:13:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C7BB616007E; Thu, 8 Nov 2018 20:13:51 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YO4PdiP7YWjq; Thu, 8 Nov 2018 20:13:51 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AF91D160044; Thu, 8 Nov 2018 20:13:50 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.DEB.2.20.1811081801580.3596@grey.csi.cam.ac.uk>
Date: Fri, 9 Nov 2018 07:13:47 +1100
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7702EE25-1B10-4880-804C-C7CF5FE609C8@isc.org>
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com> <2BDA0411-202D-4199-A43B-3FDC50DC47F5@isoc.org> <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com> <D378E8F5-A667-4649-90ED-7C3612F0A013@isoc.org> <a4087032-acb2-0f2e-f84b-31d2885d8390@bellis.me.uk> <alpine.DEB.2.20.1811081801580.3596@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uIQIKOu1IPocFmIYhtKF2b2FIhw>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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: Thu, 08 Nov 2018 20:13:55 -0000


> On 9 Nov 2018, at 5:27 am, Tony Finch <dot@dotat.at> wrote:
> 
> Ray Bellis <ray@bellis.me.uk> wrote:
>> On 08/11/2018 11:47, Dan York wrote:
>> 
>>> For that reason, wouldn't all the resolvers (or at least an extremely high
>>> %) need to be upgraded to support the new record?
>> 
>> They don't _have_ to be, but performance is improved when they are (since only
>> an upgraded resolver will include the A and AAAA answers in the additional
>> section).
>> 
>> The critical path is the browsers, since none of this works unless they
>> start looking up the HTTP record.
>> 
>> As a transition mechanism, site operators would still need to publish their
>> existing A and AAAA records by whatever means they currently do (even if
>> that's e.g. a CNAME flattening on the authority server).
> 
> The transition mechanism is really important if zone publishers are going
> to use HTTP records. It needs to be automated and invisible to the web
> site admin. If you require people to provide both a target hostname and
> the corresponding addresses, you are making it too hard. You aren't
> removing the friction caused by the restrictions on CNAMEs.
> 
> At the moment the options for setting up 3rd party hosting are:
> 
>  * Just use address records. Lots of places prefer this because it
>    always works, at the cost of less flexible static server setup.
> 
>  * Use a CNAME for www and address records for the bare domain. Maybe the
>    address records refer to a server that is more limited in some way
>    than the CNAME target (no geoIP, just a redirector, ...)
> 
> HTTP RRs risk adding a third option, where the web provider has to have
> documentation asking whether the DNS provider supports HTTP RRs and if so
> the site admin needs both these addresses and this hostname. And the
> addresses can't refer to a redirector, so this thord option opens a new
> trap for the unwary.

The providers that use CNAME add HTTP to that description and say to add HTTP
at the zone apexes or anywhere else another record is published at the same name.  

> What I would like is to eliminate the wrong choices on the DNS provider
> side of things, so that the web site admin can provide a target hostname
> which will work on any name, just like they can with address records.

Providers that synthesis A and AAAA records using proprietary methods just add the
HTTP record as a complementary record.

Providers that use CNAME at the apex set the CNAME TTL to 0 and add HTTP along side
the CNAME.  This will allow them to be able to see which clients support HTTP if they
wish.  HTTP lookups needs to be made *before* A and AAAA lookups get the HTTP records
into the resolver’s cache.

> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Fitzroy, Sole: Cyclonic 5 to 7, becoming southerly or southwesterly 7 to
> severe gale 9. Very rough or high. Rain or showers. Good, occasionally poor.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org