- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 9 May 2017 14:32:17 +1000
- To: Ilari Liusvaara <ilariliusvaara@welho.com>
- Cc: DNS Privacy Working Group <dns-privacy@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
> On 9 May 2017, at 2:29 pm, Ilari Liusvaara <ilariliusvaara@welho.com> 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/
Received on Tuesday, 9 May 2017 04:32:54 UTC