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

On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote:
>> is the draft you and Paul are working on different than
>> ietf-dnsop-dns-wireformat-http ?  Can they be reconciled?
>
> 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 :)

Is your draft h2-specific, or is it valid for http/1.x as well?

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

:) I'm not actually interested in constraining the http protocol, i'm
just trying to make something that works with existing versions of the
http protocol.  I documented my expectations of future versions of HTTP
to make sure that they're understood, which got me to your helpful point
about h2 not being client-speaks-first.  I've documented that here now,
btw:

    https://gitlab.com/dkg/hddemux/issues/5

I'd expect this draft to work with no ALPN token at all (which is the
traditional HTTP/1.1-over-TLS use case, and ALPN is still not mandatory
for TLS, right?

the "cleaner and safer" remark was from the DNS client point of view:
they already implement DNS-over-TLS, they just need to be pointed to the
right server and the right port -- that's literally no change to the
existing code, and as long as they don't indicate an alpn of "h2" they
should be safe, right?

> 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'd be happy to do that to make something like this work with HTTP/2.
I'll contact you off-list about what might be sensible next steps.

It occurs to me that an h2 CONNECT stream to localhost:53 ought to be
sufficient to do a stream-based wireformat transition (assuming that
there was a local DNS-over-TCP service active).  Does that seem right to
you?  If that's the case, then a DNS-only client would "only" need to
know enough HTTP/2 to establish the connection and to parse the incoming
frames.  Are there specific advantages of making the protocol
entanglement more complex?

----

Given that not everyone is adopting HTTP/2 right away, though, do you
think the proposed draft would be acceptable if it was limited in scope
to demuxing DNS with HTTP/1.x?

Regards,

        --dkg

Received on Thursday, 4 May 2017 01:07:25 UTC