Re: [Driu] [DNSOP] SRV and HTTP

Mark Andrews <marka@isc.org> Wed, 11 July 2018 06:21 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 E8359130EBF; Tue, 10 Jul 2018 23:21:43 -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 yyei5UxS3VbC; Tue, 10 Jul 2018 23:21:40 -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 7479E130E13; Tue, 10 Jul 2018 23:21:40 -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 16E803AB03F; Wed, 11 Jul 2018 06:21:40 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D9F4B16006A; Wed, 11 Jul 2018 06:21:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B051316006B; Wed, 11 Jul 2018 06:21:39 +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 1WPY288j99Zw; Wed, 11 Jul 2018 06:21:39 +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 C51FB16006A; Wed, 11 Jul 2018 06:21:37 +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: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se>
Date: Wed, 11 Jul 2018 16:21:35 +1000
Cc: Mark Nottingham <mnot@mnot.net>, DoH WG <doh@ietf.org>, Adam Roach <adam@nostrum.com>, driu@ietf.org, dnsop@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Joe Abley <jabley@hopcount.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A57405D3-36C4-484A-BCAF-712D356A916F@isc.org>
References: <m1fcoe5-0000GuC@stereo.hq.phicoh.net> <alpine.LRH.2.21.1807101056140.5219@bofh.nohats.ca> <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <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> <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se>
To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@frobbit.se>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/ZSO5ICG0iVDt53oajYbBlrNxcXI>
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: Wed, 11 Jul 2018 06:21:44 -0000


> On 11 Jul 2018, at 3:53 pm, Patrik Fältström <paf@frobbit.se>; wrote:
> 
> On 11 Jul 2018, at 3:30, Mark Andrews wrote:
> 
>> I think there are three main objections.
>> 
>> 1) Wildcards don’t work with prefixes.
>> 2) Additional data isn’t always returned it may require multiple round trips.
>> 3) Additional data processing doesn’t support negative responses.
> 
> 4) Various libraries in PHP and ultimately lib curl do not include SRV in the resolution

Then PHP is not STD 13 compliant.  Resolver libraries are supposed to be able resolve UNKNOWN records per STD 13 and that includes SRV.
As for lib curl, there is not a RFC that says to lookup SRV records for HTTP or HTTPS.

> 5) New resource record types are very hard to implement (same argument as why we use TXT for SPF and not SPF for example)

SPF was just plain unwillingness to complete the transition.  The code was out there.  It was being deployed.  TXT to SPF transition was never part of the experiment, it was in addition to the experiment.

No resources record is hard to implement.  What hard is getting someone to commit 30 minutes to 1 hour of time to do something at all.  That is what it takes most pieces of software to add a new record type.  Thats been true since I started in the DNS back in the early 90’s.

> 6) You "only" change hostname with SRV and not a "complete change of the URL

>> All of these issues are trivially easy to fix.  It just require willingness to implement.
>> 
>> 1) is addressed by defining a new type(s) rather than using prefixes.
>> 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.
>> 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not.
> 
> 4) Is of course "just code" in lib curl and what not
> 
> 5) Is like (4) but possibly harder if you want it implemented in PHP, javascript etc and not in the underlying libraries
> 
> 6) This is why I came up with URI which is supposed to be a competitor to "well known URI"
> 
>   paf

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