IETF Logo Mail Archive

Re: [Driu] [DNSOP] SRV and HTTP

Mark Nottingham <mnot@mnot.net> Wed, 11 July 2018 01:32 UTC

Return-Path: <mnot@mnot.net>
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 254F4130EB2; Tue, 10 Jul 2018 18:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=NYCbfOXc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y0na1WHh
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 VGH7azKCzaBf; Tue, 10 Jul 2018 18:32:08 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E109130E9E; Tue, 10 Jul 2018 18:32:08 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9D1CF21BBE; Tue, 10 Jul 2018 21:32:07 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 21:32:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQW0ZFcwV65ySt4qqfPe9vcr9 QOjwKmSeAa7pWg=; b=NYCbfOXce98kVuWEG9ADfmdO1R9Ek6Hm5ixKgvUBzyMg1 d26kZlhTJupBDJB+eAXFamjueLCOKvIZCDY0522an3Ll1L+MOVMnLbawFZgvDjrl ggFeU1+dhRhnnauuSVP/kjF4iZ+ng55WP0mUnsjeqOl6pEzxF/veXoFX+880Y7ps ffkO70SO9WgbAzIIVDtQWcoXkw9qAamna9Dr2QrwDfuERBy0St6/37DPzqaDfe3x 7s/YzeLQYb6wKCshK/1ss3ikyrtPq/05bYxKRvcrt3kFt/gOqRHSqG5V9De7B2zX H3JYeF1M9COJ6PuUF6+sh7uwcZGeYCzciFYRfpYpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQ W0ZFcwV65ySt4qqfPe9vcr9QOjwKmSeAa7pWg=; b=Y0na1WHh81Eu/3+fy4GWto sDOJH9PQaPtrntWB6OyGCTf+qi9QkrPJYm7bV//ch6h/QxMFvcKgdTys1b6YCWRe YgcK4/QHfuu5MSsl+W3l/E1NuA4C5KXl1ktZvelRyfdn/jg87uC936hZmwXphEnX YBkhVEoNwBU5+r4gS+Gftpid3GnMA4u5IXCMYxkeKX4pWPZ8+q8FtRBAB4P4RO4s 18dHLpLJKe8ZFY3sWEPAcgShno7b8bVpmYgtrVyXCsJ2witkh32PvWksSJ0veGWY Z+mFKbpKDlci1OBzVDl6ply4fkRBfkdKgkHDgEMD9d0FsAbILk5X6ZjctP2TCj5Q ==
X-ME-Proxy: <xmx:F15FW9q6192qA7hb_pSHElFb6JoKW1EtapPzCwOpCBW2872zqeS6iA> <xmx:F15FW1aw2H4JWRgvE-jOydrPwZgNwyzahQOBVju2Ck3mQJX6nR1gQw> <xmx:F15FWxD6Jknfrtrf99NydD100L6qZI0ZcVDhiEux5n492GDfBHlsng> <xmx:F15FWwFwk0wsmGxtQQP55FaGDTMTVAqQcd2Mf-8yRCNJtFu_A1u_yw> <xmx:F15FW9ykMITlihfE9ukzDJn2D0qOXRMHhNmduh0NCjPmZRF75r_2rQ> <xmx:F15FW1Ay-EYK_JP_P_I8BfmaawAc-nBLGMI2k9XlINOs6VahhPQsmQ>
X-ME-Sender: <xms:F15FW8MJ8SvyLYBqUMROLMjl6OHIzUfSUXGsFUcTJFTlG48NTFaEWA>
Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 06702E405A; Tue, 10 Jul 2018 21:32:04 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org>
Date: Wed, 11 Jul 2018 11:32:02 +1000
Cc: 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: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net>
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>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/VB94fTf1-OLEba_G90J2L66kSWc>
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 01:32:11 -0000

I didn't find those, but I found many others.

I'll start collecting. How about Tuesday, say 6:45-7:45pm?



> On 11 Jul 2018, at 11:30 am, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 11 Jul 2018, at 11:22 am, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> 
>> 
>>> On 11 Jul 2018, at 3:55 am, Joe Abley <jabley@hopcount.ca> wrote:
>>> 
>>> On Jul 10, 2018, at 18:02, Adam Roach <adam@nostrum.com> wrote:
>>> 
>>>> In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities".
>>> 
>>> *cups hand to ear*
>>> 
>>> Was that the sound of a distant desire to specify use of SRV for HTTP?
>>> 
>> 
>> I recently did some digging on this topic, and can try to characterise what the issues / objections are.
> 
> 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.
> 
> 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.
> 
> 
>> Would people be interested in a (hopefully brief) side meeting to discuss and maybe come to a shared understanding of the problem space?
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

--
Mark Nottingham   https://www.mnot.net/

v2.8.10 | Report a Bug | By Email