W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Tue, 9 May 2017 07:29:51 +0300
To: Mark Nottingham <mnot@mnot.net>
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20170509042951.GA8239@LK-Perkele-V2.elisa-laajakaista.fi>
On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote:
> Hey DKG,
> Throwing my .02 in, although it's similar to what you've heard from
> others upthread --
> I wouldn't do this for h1; it'll be an interop nightmare. H2 gives
> you the properties you want and the implementation / testing burden
> is much more realistic.
> For H2, I wouldn't use an ALPN token; define a new frame type or two
> that you can send optimistically before SETTINGS sync, stopping them
> if you don't get the right SETTING from your peer. Realistically,
> this is going to need to be configured into the client anyway, so
> there's some amount of pre-arrangement.

I don't think what you are saying is workable.

>From what I can gather, the intention for this thing DKG gave is to
be pure TLS-wrapped DNS from the client side. Any SETTINGS or otherwise
from the server breaks this. And it can not use any odd ALPN values

This impiles this thing can't be used with HTTP/2, as it is both-
sides-send-first, instead of client-sends-first.

Yes, if you try this with random HTTP server, it will choke. The
intention is that the client knows via configuration that the HTTP
server is capable of DNS demux.

The schemes for riding DNS on top of HTTP or HTTP/2 framing structure
are totally different thing. Those are obviously more compatible with

Received on Tuesday, 9 May 2017 04:30:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC