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

On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote:
> I see no reason to suggest that spraying DNS on an HTTP connection would
> be interoperable.  HTTP/1.x has a tradition (good or bad) of allowing
> robust parsing of bad messages, which means no analysis of DNS uniqueness
> can guard against the potential variance of a thousand or so independent
> implementations of servers and intermediaries (there are at least four
> figures of independent server development in the craft-your-own-microserver
> category).

Perhaps the draft needs to be clear that this draft provides guidance
for servers that *want* to be able to distinguish a DNS-over-TLS stream
from an HTTP-over-TLS stream.  According to the published specs, a
server is within its rights to not treat invalid HTTP requests as valid
HTTP requests, right?

> In contrast, it is trivial to transform a DNS query into a GET request
> which can be handled by any current or future version of HTTP.
> All you need is the absolute URI, which is already defined, and a
> media type for the response payload.  That would just be using HTTP,
> so no need to call that an update either.

Agreed on this one, quoting from the draft:

    If being able to interleave DNS queries with HTTP requests on a
    single stream is desired, a strategy like
    {{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead.

The advantage of draft-dkg-dprive-demux-dns-http over this approach is
that existing DNS-over-TLS clients (of which there are several) don't
need to learn any HTTP framing or parsing, and can simply be repointed
to a server that already supports this demultiplexing on port 443.

For folks in the HTTP world that might sound like "just use HTTP", but
for an existing DNS client, it's an entirely different codebase to adopt
(or to build), with all the attendant bugs and maintenance risks.

Regards,

        --dkg