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

[Daniel Kahn Gillmor <[e-mail]>]

Hi Patrick--

On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote:

> My initial response is that legacy HTTP/1 implementations will sink you by
> scanning for stuff that looks like HTTP in your stream - even if the
> leading bytes don't match the production those RFCs required (and HTTP/1.0
> is only informational anyhow). You can look at the websockets masking
> madness to see the lengths the community went to to avoid that kind of
> detection in rfc 6455.

Are you talking about an existing HTTP/1 server implementation?  The
idea of the demuxing stage is that a server that opts into this would
put the demuxing *before* the HTTP/1 server implementation gets access
to the data.

> Coincidentally I have a draft with Paul Hoffman that we're close to
> publishing, that describes how to do DNS over https:// in a way that I
> think will play better with both the http and dns ecosystems than previous
> work in that area. It wouldn't be a http-wg item though, we don't normally
> take FOO-over-HTTP drafts here. That might be a better option - if you want
> to use the https port, and the https alpn token, perhaps the https protocol
> (without constraining its future) is the right choice :)

is the draft you and Paul are working on different than
ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?  See my
response to Roy T. Fielding (upthread) for why the demux approach seems
cleaner and safer for clients as long as we're using stream-based
transport.

I certainly wouldn't want this work to get in the way of
ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't
think it does.  does it?

        --dkg