Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

"Mark Delany" <f4t@november.emu.st> Fri, 18 December 2015 17:56 UTC

Return-Path: <f4t@november.emu.st>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C51B37B3 for <dnsop@ietfa.amsl.com>; Fri, 18 Dec 2015 09:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 a8_Xr9b37Rfu for <dnsop@ietfa.amsl.com>; Fri, 18 Dec 2015 09:56:26 -0800 (PST)
Received: from f5.bushwire.net (f5.bushwire.net [IPv6:2607:fc50:1000:5b00::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6071B37C6 for <dnsop@ietf.org>; Fri, 18 Dec 2015 09:56:20 -0800 (PST)
Received: by f5.bushwire.net (Postfix, from userid 1001) id D27F5AC8D2; Fri, 18 Dec 2015 09:56:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2015; t=1450461379; bh=XeFK/FwCdRAMH7ydkHU7aV1qCaI=; h=Comments:Received:Date:Message-ID:From:Mail-Followup-To:To: Subject:References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To; b=C6ct35P01fyNC7Z9z/tBgdDqFXb0GTKWKXXAf+pnq8LO4nrQNAcojDBR7CRVaPOBY t2ehlw9BPNwjKwZoTKyM98KwHFBDcuKrNlxsZfa/RyoGeOTAuqPipN4zfdmcBDScwU USq6hmJmAH7RWEuRtXV9t/EdTwhO12rFRFqcE8Ys=qcE8Ys=
Comments: QMDA 0.3
Received: (qmail 44496 invoked by uid 1001); 18 Dec 2015 17:56:19 -0000
Date: Fri, 18 Dec 2015 17:56:19 +0000
Message-ID: <20151218175619.44495.qmail@f5-external.bushwire.net>
From: Mark Delany <f4t@november.emu.st>
Mail-Followup-To: dnsop@ietf.org
To: dnsop@ietf.org
References: <20151217020754.6915b71c@pallas.home.time-travellers.org> <20151217210623.620dee07@pallas.home.time-travellers.org> <20151217202024.40710.qmail@f5-external.bushwire.net> <2073641.PqY0vKhHzR@linux-85bq.suse>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <2073641.PqY0vKhHzR@linux-85bq.suse>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/lWPpaGUOw4J52FUhX7pdxL3yqm8>
Subject: Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2015 17:56:27 -0000

On 17Dec15, Paul Vixie allegedly wrote:

> > That the request pipeline order doesn't necesarily match the response
> > pipeline order is particularly unexpected in some protocols (and
> > likely non-compliant), such as HTTP < 2.0
> 
> i think this is opaque to the dns-over-http specification. that is, while http may under 
> its covers do all kinds of asynchronous things

I may not be being very clear or I may misunderstand. As far as
implementation is concerned you are of course correct. As far as the
semantics of the order of responses over HTTP, not so much.

What I was getting at is that a dns-over-http client can pipeline send
request id=1 then request id=2 and get back pipelined response id=2
then response id=1 over a single connection:

Client                    Server
 Request id=1  ---->
 Request id=2  ---->

.. time passes

             <---- Response id=2
             <---- Response id=1

That is, a dns-over-http client has to do more elaborate
request/response matching with id (+query RR) rather than rely on
submit order for matching.

This re-ordering of responses is not allowed in regular HTTP 1.* and
would almost certainly break common HTTP clients that expect pipeline
order to be maintained.

I'm not saying this is good or bad, just saying it's an important
topic for any dns-over-*stream* protocol to discuss. Least surprise
and all that.


Mark.