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

> On 9 May 2017, at 2:29 pm, Ilari Liusvaara <> wrote:
> 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
> either.
> 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
> HTTP/2.

Sorry if it wasn't clear -- what I was saying was "don't do this (DKG's proposal); do that (DNS-over-HTTP)".

Mark Nottingham

Received on Tuesday, 9 May 2017 04:32:54 UTC