Re: [Driu] [DNSOP] SRV and HTTP

"Patrik Fältström " <paf@frobbit.se> Wed, 11 July 2018 05:53 UTC

Return-Path: <paf@frobbit.se>
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 83A9B130E02; Tue, 10 Jul 2018 22:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 dxMXrxxtdsgY; Tue, 10 Jul 2018 22:53:39 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFE1126F72; Tue, 10 Jul 2018 22:53:39 -0700 (PDT)
Received: from [169.254.214.146] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 4BB7A22078; Wed, 11 Jul 2018 07:53:36 +0200 (CEST)
From: Patrik Fältström <paf@frobbit.se>
To: Mark Andrews <marka@isc.org>
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>
Date: Wed, 11 Jul 2018 07:53:35 +0200
X-Mailer: MailMate (2.0BETAr6116)
Message-ID: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se>
In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@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>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/uEzlHp8NQP4Tuix-OSL0Zcii5zc>
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 05:53:42 -0000

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

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

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