Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Mark Andrews <marka@isc.org> Tue, 18 September 2018 21:24 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 E420E1294D0 for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 14:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iqdV63RVRHio for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 14:24:30 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 736C6130E8C for <dnsop@ietf.org>; Tue, 18 Sep 2018 14:24:30 -0700 (PDT)
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 54C653AB001; Tue, 18 Sep 2018 21:24:30 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 19FFF160050; Tue, 18 Sep 2018 21:24:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E0A6F1600AE; Tue, 18 Sep 2018 21:24:29 +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 U-0Q2EMB0whW; Tue, 18 Sep 2018 21:24:29 +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 C0B7D160050; Tue, 18 Sep 2018 21:24:28 +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: <201809182002.w8IK2h4E001689@atl4mhob08.registeredsite.com>
Date: Wed, 19 Sep 2018 07:24:25 +1000
Cc: Mukund Sivaraman <muks@mukund.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B9B4571-45EF-4CB3-849E-4056B159540E@isc.org>
References: <201809182002.w8IK2h4E001689@atl4mhob08.registeredsite.com>
To: JW <jw@pcthink.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/np0Tpdzp9iCVfCoP7lchh4nwIMk>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
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, 18 Sep 2018 21:24:32 -0000


> On 19 Sep 2018, at 6:02 am, JW <jw@pcthink.com>; wrote:
> 
> 
> -------- Original message --------
> From: Mark Andrews <marka@isc.org>;
> 
> > I would also expect a relatively large client population using SRV records
> > given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
> > work for lots ofother protocols.  SRV records also make it through
> > firewalls and IDS today.
> >
> 
> Hi Mark,
> 
> I agree SRV is the obvious choice for a greenfield protocol but there is HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten scripts, lonely IOT devices, and troubleshooting guides are going to be as easy to solve as updating chrome and firefox.

Actually it really is.  Think about the names that are served by CDN’s, the other data
at those names and the clients that are making those lookups.  Those names with other
data are the ones that need to me moved to using SRV.  The rest of the HTTP lookups
can continue to use A and AAAA lookup in perpetuity if they want.  Sure we want to
upgrade the rest over time but it is mostly browsers that are doing these lookups
where there is the other data issues.

As for scripts, you upgrade the tools those scripts use: curl(libcurl), wget, fetch
for SH. File::Fetch for perl.  Similar for the other scripting languages. Very few
applications actually make socket calls directly for http. 

Mark

> Whatever the solution, I feel it should be as transparent to the client as possible.  CNAME would fit this bill but the negative impact is largely unknown.
> 
> Perhaps defining a set of default protocols for SRV where it could simulate a CNAME-like response if https/http SRV records are found?
> 
> /John
> 
> >
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, 
> > NSW 2117, Australia
> > PHONE: +61 2 9871 4742              
> > INTERNET: marka@isc.org
> 

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