- 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>
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. -Ilari
Received on Tuesday, 9 May 2017 04:30:26 UTC