Re: [DNSOP] SRV and HTTP

Mark Andrews <marka@isc.org> Wed, 25 July 2018 16:56 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CF0130E77 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 25 Jul 2018 09:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.651
X-Spam-Level:
X-Spam-Status: No, score=-7.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, 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 344vURnA_rCB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 25 Jul 2018 09:56:13 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (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 3B2B2130E29 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 25 Jul 2018 09:56:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1fiMOd-0004os-Nh for ietf-http-wg-dist@listhub.w3.org; Wed, 25 Jul 2018 16:12:15 +0000
Resent-Message-Id: <E1fiMOd-0004os-Nh@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1fiMOb-0004o2-QN for ietf-http-wg@listhub.w3.org; Wed, 25 Jul 2018 16:12:13 +0000
Received: from raoul.w3.org ([128.30.52.128]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1fiMOV-0005Iq-Mw for ietf-http-wg@w3.org; Wed, 25 Jul 2018 16:12:12 +0000
Received: from capoun.raubacapeu.net ([128.30.54.81] helo=[192.168.42.1]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1fiMOV-0001xy-AL for ietf-http-wg@w3.org; Wed, 25 Jul 2018 16:12:07 +0000
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Content-Type: text/plain; charset="utf-8"
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20180712004835.GB9723@localhost>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Thu, 12 Jul 2018 01:30:54 +0000
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
Resent-Date: Wed, 25 Jul 2018 09:12:06 -0700
Message-Id: <BBFEF9CF-C37A-47D5-ADF9-C8052414FBDB@isc.org>
Resent-To: HTTP Working Group <ietf-http-wg@w3.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>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1fiMOV-0005Iq-Mw 42f71ee82c7fff7cfcdd1891a6d584c1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [DNSOP] SRV and HTTP
Archived-At: <https://www.w3.org/mid/BBFEF9CF-C37A-47D5-ADF9-C8052414FBDB@isc.org>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35716
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>


> 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