Re: [Http-srv] Alternative to SRV?

Mark Andrews <marka@isc.org> Wed, 22 August 2018 04:45 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 B836A130DE7 for <http-srv@ietfa.amsl.com>; Tue, 21 Aug 2018 21:45:59 -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 ACeBQsA5N0Zn for <http-srv@ietfa.amsl.com>; Tue, 21 Aug 2018 21:45:58 -0700 (PDT)
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 1197412F1A6 for <Http-srv@ietf.org>; Tue, 21 Aug 2018 21:45:58 -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 B12D83AB001; Wed, 22 Aug 2018 04:45:56 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 74BDE160036; Wed, 22 Aug 2018 04:45:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5BCFC160090; Wed, 22 Aug 2018 04:45:41 +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 oCV2o3EnvN-x; Wed, 22 Aug 2018 04:45:41 +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 84C20160036; Wed, 22 Aug 2018 04:45:40 +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: <CABkgnnXAYnAwThzpNBUgOtCJm7_YsGzxrbf3D8Skra+JEufxKg@mail.gmail.com>
Date: Wed, 22 Aug 2018 14:45:38 +1000
Cc: Ray Bellis <ray@bellis.me.uk>, Http-srv@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2B2A0B3-0B98-4DD1-A8CF-7067B1B0D62E@isc.org>
References: <6aceab29-cf81-8644-20cd-e02281e6394c@bellis.me.uk> <DDFF92A9-9F1D-4883-AF5C-1372EBDAB156@isc.org> <CABkgnnU8NkayO=PANGSG8Eh_rajwu2bdjLSDZ5f_15KwTqhKQA@mail.gmail.com> <81377D4F-DECA-4201-A286-FF750B5D9723@isc.org> <CABkgnnXAYnAwThzpNBUgOtCJm7_YsGzxrbf3D8Skra+JEufxKg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-srv/-A9yqWSgMRxlItxcQA7LutBKUJ8>
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: Wed, 22 Aug 2018 04:46:00 -0000

> On 22 Aug 2018, at 1:25 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On Wed, Aug 22, 2018 at 12:56 PM Mark Andrews <marka@isc.org> wrote:
>>> On 22 Aug 2018, at 10:44 am, Martin Thomson <martin.thomson@gmail.com> wrote:
>>> 
>>> I think that you are free to pretend that HTTPS is the only variant of
>>> the protocol.  There's no point in shipping improvements for the
>>> cleartext variant.
>> 
>> We have to make stuff work for http as well as https.  There are still sites
>> that want to use http at the zone’s name where CNAME doesn’t work.  This is a
>> CURRENT problem.
> 
> My point is that we don't have to fix http.  It's a broken protocol
> that we support for backwards-compatibility reasons.

We are fixing http we are fixing lack of service to server mapping for HTTP
and HTTPS that will work *everywhere* in the DNS namespace.

>>> What are you thinking about ALPN?
>> 
>> What are you thinking about?  The default would be the status quo.  I would
>> like to be able to deploy this without requiring servers (excludes proxies)
>> to be updated.
> 
> If you take a narrow view and say that we just need A++ or AAAA++, we
> get a design that has no real incentive to deploy.  But if we were to
> make it easier to deploy QUIC (for example), that might be a valuable
> inducement.

QUIC is a pseudo transport.  _https._quic

I’m not going to object to doing something more but too much feature creep
will make this a long process.  If you want DNS servers to fill in the additional
section make the record well structured.  Conversion from txt to wire format is
time consuming.  Nameservers work in wire format.

I suspect the starting point of a new record would be a PTR/CNAME analog.

		<site> HTTP <server>

If you want to add alternate transports

		<site> HTTP <transport> <server>

then you add “A and AAAA records SHOULD retrieved and added to the additional
section prior to returning the response to the HTTP query”.

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