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

[Mark Nottingham <[e-mail]>]

> On 9 May 2017, at 2:29 pm, Ilari Liusvaara <[e-mail]> 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   https://www.mnot.net/