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

On Wed, May 3, 2017 at 7:17 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> 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 whole ecosystem - so lbs, av, firewalls, etc.. roy makes a similar
point.


>
> > 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
>

its a superset of that -more aligned with HTTP than that draft, but it can
also carry wireformat.

your work doesn't break it anymore than it breaks h2 generally :)



> 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 totally support the end goal here of dns looking like https.. but
honestly I didn't hear anything about cleaner and safer. I heard that you
wanted to use the https port, the https alpn token, and constrain the http
protocol, but found the requirement to implement http burdening :) The most
straightforward way seems to make dns look like https is to actually carry
it in https.

perhaps we could work together on making a dns client more capable in this
regard?



> 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
>