Re: [Http-srv] Alternative to SRV?

Mark Andrews <marka@isc.org> Tue, 21 August 2018 23:40 UTC

Return-Path: <marka@isc.org>
X-Original-To: http-srv@ietfa.amsl.com
Delivered-To: http-srv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C2B130F58 for <http-srv@ietfa.amsl.com>; Tue, 21 Aug 2018 16:40:17 -0700 (PDT)
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 9KhpTwQh9ZrH for <http-srv@ietfa.amsl.com>; Tue, 21 Aug 2018 16:40:15 -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 1CE80130F21 for <Http-srv@ietf.org>; Tue, 21 Aug 2018 16:40:15 -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 9CB9D3AB043; Tue, 21 Aug 2018 23:39:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 67C66160050; Tue, 21 Aug 2018 23:39:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 54289160090; Tue, 21 Aug 2018 23:39:15 +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 BbZLPLU6NJsh; Tue, 21 Aug 2018 23:39:15 +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 AA720160050; Tue, 21 Aug 2018 23:39:14 +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: <6aceab29-cf81-8644-20cd-e02281e6394c@bellis.me.uk>
Date: Wed, 22 Aug 2018 09:39:12 +1000
Cc: Http-srv@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDFF92A9-9F1D-4883-AF5C-1372EBDAB156@isc.org>
References: <6aceab29-cf81-8644-20cd-e02281e6394c@bellis.me.uk>
To: Ray Bellis <ray@bellis.me.uk>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-srv/VrOqkJ7BMpFHUEbgh-TlQG5Enjg>
Subject: Re: [Http-srv] Alternative to SRV?
X-BeenThere: http-srv@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Using DNS SRV Records with HTTP <http-srv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-srv>, <mailto:http-srv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-srv/>
List-Post: <mailto:http-srv@ietf.org>
List-Help: <mailto:http-srv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-srv>, <mailto:http-srv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 23:40:30 -0000


> On 22 Aug 2018, at 4:39 am, Ray Bellis <ray@bellis.me.uk> wrote:
> 
> Thanks Adam, for creating the mailing list.
> 
> As mentioned at the side-meeting in Montreal, I strongly believe that the way forward should be a new RR that is specific for the use of HTTP(s) (c.f. MX for SMTP) and that would be automatically looked up by recursive resolvers and returned in answers [*]
> 
> This recursive lookup step would give this record the equivalent performance to CNAME whilst avoiding the complexities (and failings) of SRV or ANAME.
> 
> I'd like to write that up in a draft, but to do so I'd like to co-author  with HTTP specialists to ensure that any such RR has the fields they deem necessary without the extra ones that SRV has that we heard are not desirable (specifically port numbers and load-balancing / weighting).

Only the port field is a real potential issue with HTTP.  The others can be set appropriately.
I wish we had said port==0 implies use the default/specified port.   We could still say this for
_http._tcp and _https._tcp.  Part of the reason SRV doesn’t automatically cover a protocol but
requires that SRV use be specified for a protocol is to allow for changes like this.

> Who'd be up for helping with this?
> 
> Ray Bellis
> ISC Research Fellow
> 
> [*] one caveat - the look-up would have to be optional in the specification because making it mandatory would prevent the use of the RR Expert Review process which doesn't allow for the assignment of
> RRs with mandatory server side processing.
> 
> -- 
> Http-srv mailing list
> Http-srv@ietf.org
> https://www.ietf.org/mailman/listinfo/http-srv

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