Re: [Driu] [DNSOP] SRV and HTTP

Mark Andrews <marka@isc.org> Thu, 12 July 2018 01:30 UTC

Return-Path: <marka@isc.org>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DE130DC7; Wed, 11 Jul 2018 18:30:25 -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 q1UkgWiTfb9x; Wed, 11 Jul 2018 18:30:23 -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 2EF9512F1A2; Wed, 11 Jul 2018 18:30:23 -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 EC7313AB03F; Thu, 12 Jul 2018 01:30:21 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D5F39160076; Thu, 12 Jul 2018 01:30:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0567160075; Thu, 12 Jul 2018 01:30:21 +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 vorCVgjZ3GOH; Thu, 12 Jul 2018 01:30:21 +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 71EEA160043; Thu, 12 Jul 2018 01:30:19 +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: <20180712004835.GB9723@localhost>
Date: Thu, 12 Jul 2018 11:30:16 +1000
Cc: Mark Nottingham <mnot@mnot.net>, Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org, DoH WG <doh@ietf.org>, Adam Roach <adam@nostrum.com>, driu@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBFEF9CF-C37A-47D5-ADF9-C8052414FBDB@isc.org>
References: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com> <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com> <e658445a-242b-5f94-f1fc-0bc4c850319d@nostrum.com> <CAJhMdTOPjhbOK=NQijnYZ3kCY_+f-87n7wwwuR38ifHUG5msqA@mail.gmail.com> <F6C1AF50-EB1B-4E09-9A72-229AD4AC7E57@mnot.net> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> <20180712004835.GB9723@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/Yji3jRCs-49-8pHRT7HLotUpt30>
Subject: Re: [Driu] [DNSOP] SRV and HTTP
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2018 01:30:25 -0000


> On 12 Jul 2018, at 10:48 am, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote:
>>>>> 1) is addressed by defining a new type(s) rather than using prefixes.
>>> 
>>> While that is correct, and truly, it is trivial to implement, it is not
>>> trivial to deploy: too many DNS hosting providers would have to update
>>> UIs.
>> 
>> Garbage.  There really isn’t.  People keep saying something can’t be done
>> because there are too many X.  X get replaced.  X get updated.  As for DNS
>> hosting providers that support a given type, we create a site and report
>> what software by version and date and what DNS hosting providers support
>> the type native or unknown formats.
> 
> I didn't mean to say not to go this way.  On the contrary, we should.
> Just that this is an issue.
> 
>> We also don’t have to achieve 100%.  People can move to DNS hosters that
>> do support the type or host their own DNS.  Every DNS hoster that provides
>> slave/secondary services already supports they type as UNKNOWN has been out
>> there so long.
> 
> Ah yeah, that's true -- not a great UI, but it works.
> 
>>>>> 2) is addressed by getting recursive servers to fill in missing additional data before returning.  Named has code in review for this for SRV as proof of concept.
>>> 
>>> That would be very nice indeed.  Unbound will need that too.
>>> 
>>>>> 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not.
>>> 
>>> Well, OK, but as with (2) that requires recursive resolver critical
>>> mass.  Not necessarily a big deal, though it will take enough time that
>>> many apps will need to support falling back to doing multiple queries
>>> one by one.
>> 
>> They can do the queries in parallel, that 2 RTTs.
> 
> Yes, that's a big deal.

It’s a self correcting problem though.  Recursive nameservers do get upgraded.

If we could have got people on board back when I first submitted
https://datatracker.ietf.org/doc/draft-andrews-http-srv/ everyone would be using
it and I suspect recursive servers would have been optimised to fetch the additional
data before returning.  There is nothing in the RFC’s that says you can’t stall the
response to fetch additional data.  This isn’t hard.  It just requires people to
stop arguing and “Just Do It”.

Also writing documentation that says “if the query has these properties, fetch missing
additional data” will help.

We could have done 5 or 6 transitions since 2000 on both the DNS and HTTP sides.
While there are long tails most of the world upgrades within 3 years.

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